Customer authentication for credit card, debit card, and banking users is a critical function that has yielded sub-optimal results. Customer authentication is generally initiated when a customer acquires an account or attempts to use or service the acquired account through one or more of a number of channels. Today, the process of customer authentication is often inconsistently supported across channels such as Internet, phone, bank branches, and ATMs. Currently, financial institutions embed authentication policy within each internal application and the applications accessed may vary depending on the channel through which interaction occurs.
The above-identified parent application proposes a solution to enable customers to experience consistent authentication processes when attempting a variety of actions, such as new account screening, transaction authentication, and servicing authentication, through one of a number of channels. Such channels may include, for example, telephone, face-to-face, and web channels. Multiple applications may include a VRU application, a Branch application, and web applications. A centrally managed authentication and interaction tracking platform is provided, enabling customers to experience consistent treatment when entering the system through any given channel. Using the central authentication and interaction tracking system, an ability is created to quickly adapt to new threats and emerging technologies. The proposed authentication model is additionally capable of leveraging cross-channel transactions or behavioral risk so as to apply authentication policy based on a level of risk associated with the channel and transaction type. Furthermore, the proposed system adds a risk assessment component to identify certain acts as involving more risk than others.
Another difficulty with the existing systems is that they fail to combat increasingly sophisticated fraud techniques. Perpetrators of fraud strive to find the point of least resistance and continue to access the system through that point. Often, transactions are authenticated based on multiple customer authentication factors. Typically these factors include: (1) something the customer knows; (2) something the customer is; and (3) something the customer has. With respect to the first factor, something the customer knows may include such things as a username, password, and security questions. These factors can be easily compromised and are increasingly at risk for being used to perpetrate fraud. Fraudulent actors have an increasing number of information sources available such as email accounts and social media accounts, from which to acquire personal information. What the customer “knows” has historically been one of the weakest security measures against fraud. With regard to the second category of factors, what the customer “is” may take the form of an IP address or caller ID. However, even with this second category of authentication factor, computers and mobile phones are frequently targets of theft and can be accessed and used by fraudulent actors. With the third category of information, things that the customer has may include RSID tokens or payment cards. These identifiers can also be easily stolen. Biometric indicators such as fingerprints and retinal prints also fall into this category and may generally be more reliable indicators but are not currently frequently used.
Existing financial processing systems often rely on one or two of the above-identified easy-to-compromise methods to authenticate transactions. Even two-step authentication methods that rely upon dynamic token passwords have been more frequently compromised. Detection of fraudulent transactions has also been a challenge because data used for authentication may change over time. Customers may forget passwords, lose credit cards, or change phones, for example. The failure of one or more authentication attempts is not necessarily, in itself, an indication of fraud.
A fourth category of information includes “something you do”. This relates to a pattern of activity. For example, certain entities may frequently use an ATM machine, make purchases online, or dine at a specific restaurant. The entities may perform these actions on particular dates, weeks, or months, at fairly regular times. This category is less frequently used for authentication purposes.
Thus, the security policies of authentication systems typically do not take into consideration activities and historical actions across all channels and applications. Historical actions can be indicative of valid future actions as well as of fraudulent future actions. Additionally, levels of risks may be associated not only with actions, but also with particular entities. Existing systems often fail to take this fact into account during authentication processing.
Additionally, while it has been suggested that a transaction risk level may be considered, existing systems do not take into consideration a risk level of the entity instigating the transaction, interaction, or event. While many entities interacting with financial institutions are customers, other entities may include employees, third party providers, or unrelated individuals. Historical interactive patterns of entities can be indicative of their risk level.
Thus, a solution is needed that takes into account historical patterns and deviations from historical patterns. The system should account for both entity risk and transaction risk during authentication. The solution should be centrally managed and executed in order to support appropriate, specific, and consistent strategies across all channels and applications.